The J2EE Web application technology has already been widely adopted in the field of enterprise-level application, but nowadays, for the continuously increasing of scale and complexity of enterprise-level software, modularized design and development of software and a “front shop back factory” type software architecture which supports releasing according to service characteristics are gradually becoming the trend of development. Modularized development and design of Web applications are objectives pursued by software architects and developers all the time, but lack the support of unified specification and architecture.
The OSGi enterprise-level specification (OSGi 4.2) provides a good support for running the J2EE Web applications under a plug-in environment, and formulates a specification (Web Applications Specification) that a plug-in runtime environment supports Web applications, which makes the Web applications have the capabilities of modularized development and running and dynamic variability and expandability. The J2EE Web application may be smoothly migrated to run under the OSGi architecture, and the existing application may run under the OSGi architecture without great adjustment, so that the cost is greatly reduced. A service logic layer (Enterprise Bean) has the capabilities of modularization and dynamic expandability.
Modularization of a web layer of a service characteristic bundle is realized by using Fragment in the prior art, specifically, the Web layer of the service characteristic bundle is packaged into the Fragment and attached to a basic WAB (Web Application Bundle, WAB), so that when the basic WAB is started, the Web resource in the Fragment is loaded at the same time, but the Fragment does not have a life cycle and thus dynamic expansion can not be realized; if the Fragment depends on a class which is not depended on by the basic WAB, the Fragment can not be added to runtime environment in a running state, and the basic WAB must be restarted; moreover, once the Fragment is loaded to run, the Fragment can not be dynamically unloaded; and the basic WAB needs to be restarted if the Fragment is required to be unloaded, which will affect normal use of other service characteristics.
In the single sign on (Single Sign On, SSO) scheme of the prior art, since each independent service characteristic WAB must comprise all resources so that it may run, then the problem that the same resource simultaneously exists in different service characteristic WABs exists in a complete application, which leads to the repeated deployment of the resource; and if a certain basic resource is required to be updated, all involved service characteristic bundles are required to be synchronously modified, which greatly increases complexity and maintenance cost of the applications.